This PR fixes the bug where subsequent builds would cause the .open-next output directory to be recursively bundled within itself, leading to exponential growth in bundle size and slow build times.

What the issue is

I used OpenNext to build my Nextjs app with Prisma a couple times until I got an error:

Failed to compile.

Error: ENAMETOOLONG: name too long, readlink 

.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/.open-next/server-functions/default/apps/[app-name]/app/generated/prisma/schema.prisma

1. If I do rm -rf .next .open-next then npx --yes @opennextjs/aws@latest build first for a clean build, there is no issue.
2. Run a Second Build (Without Cleaning)
   Now, run the build command again without deleting the .open-next directory. This will trigger the bug.

npx --yes @opennextjs/aws@latest build

3. I then checked the Nextjs traces:

• .next/server/app/page.js.nft.json (for the root App Router page)
• .next/server/pages/api/some-route.js.nft.json (for a Pages Router API route)

It will contain a JSON object with a files array. This array lists all the file paths that Next.js determined are dependencies.

Search for the string .open-next inside this file.

On the first (clean) build, I will NOT see any paths containing .open-next. The paths will correctly point to the source code or node_modules, like this:

{
  "version": 1,
  "files": [
    "../../node_modules/some-package/index.js",
    "../../prisma/schema.prisma"
  ]
}

On the second build, I WILL see paths that point into the previous build's output directory:

{
  "version": 1,
  "files": [
    "../../node_modules/some-package/index.js",
    "../../prisma/schema.prisma",
    "../../.open-next/server-functions/default/prisma/schema.prisma"
  ]
}

This issue is not exclusive to Prisma. It can occur with any library or tool that requires access to local source code files at runtime and is used in server-side code.

The key conditions are:

• A library's runtime code needs to read a file from the project's source tree (e.g., a schema, a config file, or content files).
• server-side code (like a Server Action or API route) imports and uses that library, causing Next.js to trace those local files as dependencies.

The Simple Fix

The core of the problem was a feedback loop in the build process.
Before the Fix (Incorrect Order):

1. next build would run first.
2. The build process would scan the project for dependencies and find files in the old .open-next directory from the previous run.
3. The .open-next directory would then be deleted.
4. The new build would be created using the incorrect dependency list, causing a recursive copy.

After the Fix (Correct Order):

1. The .open-next directory is deleted first, ensuring a clean slate.
2. next build runs, scanning a clean project and generating a correct list of dependencies.
3. The new build is created without any recursive artifacts.

While it is possible to fix it with this flag in next.config.ts below. It is still a workaround and adds config debt so I think changing the building step order is a more ideal fix.

const nextConfig: NextConfig = {  
  // This tells Next.js's file tracer to ignore all files and folders
  // inside the .open-next directory.
  outputFileTracingExcludes: [".open-next/**/*"],
};

#951
Issue I Submitted
Reproduction Repo